Typically, an H.264 transport stream contains at least one I-Frame in a two (2) second video fragment. Considering the number of users on field and specialized video streams (e.g., customized video streaming of the EPG (electronic program guide) screens to each user), a sheer bandwidth issue is created, and it becomes virtually impossible for a broadcaster to have I-Frames inserted at regular intervals for each user. Therefore, these specialized or customized video streams generally only contain a single I-Frame at the beginning of the stream, the single I-Frame being followed by only PB Slices. Unless the user goes into a menu that has an entirely different user interface, another I-Frame may not be sent at all.
The service acquisition process across typical set-top boxes (STB) generally adheres to the following steps:                (1) On a tuner lock on the QAM (quadrature amplitude modulation) path or on a lock on the IP (Internet protocol) path for HLS (HTTP live streaming), read and buffer up an entire block of the content. This is done immediately after the lock acquisition. The purpose of this buffer is to complete the acquisition process. This buffer can be termed as the “Acquisition Buffer”.        (2) Parse the Acquisition Buffer to look for the PAT and PMT SI tables and obtain all the PID information required.        (3) Program the PIDS on the Demux/Decoders, declare the acquisition was successful, and discard the Acquisition Buffer.        (4) Look for the next I-Frame and present the video subsequently after that.        
With a typical transport stream, the acquisition process described above is sufficient as the typical transport stream contains repeating I-Frames.
However, with a specialized or customized content stream (e.g., guide streams, etc.), the single and only I-Frame at the beginning of the content stream is consumed as part of the Acquisition Buffer, and the service acquisition module is unable to find subsequent I-Frames. Hence, no video is rendered and the screen stays blank.
Further, in the case of content streams which do have successive I-Frames but the first I-Frame is important to use or understand the content (e.g., a gaming video that is streamed to the user in which the very first I-Frame shows the instructions to play the game), missing this crucial I-Frame can defeat the purpose of the content.
Moreover, H.264 specifications allow for very long GOPs (group of pictures) in a H.264 transport stream. Therefore, if a H.264 transport stream contains an I-Frame in the beginning and the next I-Frame occurs after a significantly long time or never occurs at all, it is still a compliant stream. In the scenario where a STB successfully tunes to the first I-Frame and starts playing the video, and a hand-held device (e.g., a mobile device such as a tablet, mobile device, etc.) connects to the STB to lock on to the same content to play, the hand-held device may be unable to play the content as it would only receive the P and B Frames since the I-Frame was consumed by the STB. If the next I-Frame does not occur at all, the hand-held device may never be able to play the content.
Therefore, it is desirable to improve upon methods and systems for transferring content from a buffer to a decoder for content playback.
Like reference numbers and designations in the various drawings indicate like elements.